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Abstract 
This memo defines a registry for IP Performance Metrics (IPPM). It 


assigns and registers an initial set of OBJECT IDENTITIES to 
currently defined metrics in the IETF. 


This memo also defines the rules for adding IP Performance Metrics 
that are defined in the future and for encouraging all IP performance 
metrics to be registered here. 


IANA has been assigned to administer this new registry. 
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Le 


The Internet-Standard Management Framework 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to section 7 of 
RFC 3410 [RFC3410]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. MIB objects are generally 
accessed through the Simple Network Management Protocol (SNMP). 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI). This memo specifies a MIB 
module that is compliant to the SMIv2, which is described in STD 58, 
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 
[RFC2580]. 


Overview 


This memo defines a registry of the current metrics and a framework 
for the integration of future metrics for the following reasons: 


o to permit metrics to be clearly referenced by MIB modules or other 
data models; 


o to provide metrics identifiers for measurement interoperability; 


o to take special care with the integration of future standardized 
metrics because it is a continuous process; 


o to provide room where other standards bodies can register their 
metrics in order to encourage IP performance metrics to have 
OBJECT IDENTITIES rooted at a common point because the intent of 
the IPPM WG is to cooperate with other appropriate standards 
bodies (or fora) to promote consistent metrics; 


o and, similarly, to provide room for enterprises to register 
metrics. 


IP Performance Metrics Registry Framework 


MIB modules need to be able to reference IPPM Metrics precisely. The 
registry associates an OBJECT-IDENTITY with each metric. For 
example, Type-P-One-way-Delay and Type-P-One-way-Delay-Poisson-Stream 
have different OBJECT IDENTITIES. 


The registry has one branch. Metrics are identified in the 
'ianalppmMetrics' subtree. 
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This document defines an initial registry of the existing metrics 
defined in the IPPM WG and the rules to manage the registry. 
Documents defining metrics in the future will include in the IANA 
section the registration information to identify these metrics 
unambiguously. 

4. Initial IPPM Metrics Registry Creation 
The initial registry identifies the metrics currently defined in the 
RFCs produced in the IPPM WG. To date, the IPPM WG defined 33 
metrics related to the following 7 topics: 

1.  IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678] 
2. One-way Delay Metrics, RFC 2679 [RFC2679] 

3. One-way Packet Loss Metrics, RFC 2680 [RFC2680] 

4. Round-trip Delay Metrics, RFC 2681 [RFC2681] 

5. One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357] 

6. IP Packet Delay Variation Metric, RFC 3393 [RFC3393] 

7.  IPPM Metrics for periodic streams, RFC 3432 [RFC3432] 


These are sequentially registered in the node ianalppmMetrics. 


The naming conventions used for the existing metrics, and encouraged 
for new IPPM metrics, are: 


o Metrics names conform SMIv2 rules for descriptors defined in 
section 3.1 of [RFC2578]; 


o The name starts with the prefix 'ietf'; 
o ‘’Type-P’ prefix is removed; 
o ^'-' are removed; 


o The letter following a '-' is changed to uppercase. 
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5. IANA Considerations 


This section describes the rules for the management of the registry 
by IANA. 


5.1. Management Rules 


Registrations are done sequentially by IANA in the ianaIppmMetrics 
subtree on the basis of 'Specification Required', as defined in 
[RFC2434]. 


The reference of the specification must point to a stable document 
including a title, a revision, and a date. 


The name always starts with the name of the organization and must 
respect the SMIv2 rules for descriptors defined in section 3.1 of 
[RFC2578]. 


A document that creates new metrics would have an "IANA 
Considerations" section in which it would describe new metrics to be 
registered. 


An OBJECT IDENTITY assigned to a metric is definitive and cannot be 
reused. If a new version of a metric is produced, then it is 
assigned with a new name and a new identifier. 


5.2. Registration Template 


The following is a proposed template to insert in the IANA 
considerations section. For each metric, that section would 
instantiate the following statement: 


IANA has registed the following metric in the IANA-IPPM-METRICS- 
REGISTRY-MIB: 


aNewMetricName OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"The identifier for a new metric." 
REFERENCE 
"Reference R, section n." 
::= ( ianalppmMetrics nn } -- IANA assigns nn 


6. Initial IPPM Registry Definition 
IANA-IPPM-METRICS-REGISTRY-MIB DEFINITIONS ::- BEGIN 


IMPORTS 
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OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 
FROM SNMPv2-SMI; 


ianalppmMetricsRegistry MODULE-IDENTITY 
LAST-UPDATED "2005072800002" -- July 28, 2005 
ORGANIZATION "IANA" 

CONTACT-INFO "Internet Assigned Numbers Authority 


Postal: ICANN 
4676 Admiralty Way, Suite 330 
Marina del Rey, CA 90292 


Tel: +1 310 823 9358 
E-Mail: iana@iana.org" 


DESCRIPTION 
"This module defines a registry for IP Performance Metrics. 


Registrations are done sequentially by IANA in the ianaIppmMetrics 
subtree on the basis of 'Specification Required', as defined in 
[RFC2434]. 


The reference of the specification must point to a stable document 
including a title, a revision, and a date. 


The name always starts with the name of the organization and must 
respect the SMIv2 rules for descriptors defined in section 3.1 of 
[RFC2578]. 


A document that creates new metrics would have an IANA 
considerations section in which it would describe new metrics to 
be registered. 


An OBJECT IDENTITY assigned to a metric is definitive and cannot 
be reused. If a new version of a metric is produced, then it is 
assigned with a new name and a new identifier. 


Copyright (C) The Internet Society (2005). The initial version of 
this MIB module was published in RFC 4148; for full legal notices 
see the RFC itself or 
http://www.ietf.org/copyrights/ianamib.html." 


REVISION "2005072800002" -- July 28, 2005 
DESCRIPTION 
"Initial version of the IPPM metrics registry module. 
This version published as RFC 4148." 
::— í mib-2 128 } 
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ianalppmMetrics OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Registration point for IP Performance Metrics." 
::= { ianalppmMetricsRegistry 1 ) 


-- Registry of the metrics of the IPPM WG RFCs 


-- RFC 2678 "IPPM Metrics for Measuring Connectivity" 


ietfInstantUnidirConnectivity OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Instantaneous-Unidirectional-Connectivity" 
REFERENCE "RFC2678, section 2." 
::= ( ianaIppmMetrics 1} 


ietfInstantBidirConnectivity OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Instantaneous-Bidirectional-Connectivity" 
REFERENCE "RFC2678, section 3." 
::= ( ianaIppmMetrics 2} 


ietfIntervalUnidirConnectivity OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Interval-Unidirectional-Connectivity" 
REFERENCE "RFC2678, section 4." 
::= { ianaIppmMetrics 3 } 


ietfIntervalBidirConnectivity OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Interval-Bidirectional-Connectivity" 
REFERENCE "RFC2678, section 5." 
::= { ianaIppmMetrics 4 } 


ietfIntervalTemporalConnectivity OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P1-P2-Interval-Temporal-Connectivity" 
REFERENCE "RFC2678, section 6." 
::= { ianaIppmMetrics 5 } 
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-- RFC 2679 "A One-way Delay Metric for IPPM" 


ietfOneWayDelay OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Delay" 
REFERENCE "RFC2679, section 3." 
::= ( ianaIppmMetrics 6 } 


ietfOneWayDelayPoissonStream OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Delay-Poisson-Stream" 
REFERENCE "RFC2679, section 4." 
::= ( ianaIppmMetrics 7 } 


ietfOneWayDelayPercentile OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Delay-Percentile" 
REFERENCE "RFC2679, section 5.1." 
::= { ianaIppmMetrics 8 } 


ietfOneWayDelayMedian OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Delay-Median" 
REFERENCE "RFC2679, section 5.2." 
::= { ianaIppmMetrics 9 } 


ietfOneWayDelayMinimum OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Delay-Minimum" 
REFERENCE "RFC2679, section 5.3." 
::= { ianaIppmMetrics 10 } 


ietfOneWayDelayInversePercentile OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Delay-Inverse-Percentile" 
REFERENCE "RFC2679, section 5.4." 
:= { ianalppmMetrics 11 ) 
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-- RFC 2680 "One-way Packet Loss Metric for IPPM" 


ietfOneWayPktLoss OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Packet-Loss" 
REFERENCE "RFC2680, section 2." 
::= { ianalppmMetrics 12 } 


ietfOneWayPktLossPoissonStream OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Packet-Loss-Poisson-Stream" 
REFERENCE "RFC2680, section 3." 
::= { ianaIppmMetrics 13 } 


ietfOneWayPktLossAverage OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Packet-Loss-Average" 
REFERENCE "RFC2680, section 4." 
::= { ianaIppmMetrics 14 ) 


-- RFC 2681 "A Round-trip Delay Metric for IPPM" 


ietfRoundTripDelay OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Round-trip-Delay" 
REFERENCE " section 2 of the rfc2681." 
::= { ianaIppmMetrics 15 } 


ietfRoundTripDelayPoissonStream OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Round-trip-Delay-Poisson-Stream" 
REFERENCE "RFC2681, section 4." 
::= ( ianaIppmMetrics 16 } 


ietfRoundTripDelayPercentile OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Round-trip-Delay-Percentile" 
REFERENCE "RFC2681, section 4.1." 
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::= { ianalppmMetrics 17 } 


ietfRoundTripDelayMedian OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Round-trip-Delay-Median" 
REFERENCE "RFC2681, section 4.2." 
:= { ianalppmMetrics 18 } 


ietfRoundTripDelayMinimum OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Round-trip-Delay-Minimum" 
REFERENCE "RFC2681, section 4.3." 
:= { ianalppmMetrics 19 } 


ietfRoundTripDelayInvPercentile OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-Round-trip-Inverse-Percentile" 
REFERENCE "RFC2681, section 4.4." 
:= { ianalppmMetrics 20 } 


-- RFC 3357: "One-way Loss Pattern Sample Metrics" 


ietfOneWayLossDistanceStream OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-Way-Loss-Distance-Stream" 
REFERENCE " RFC3357, section 5.4.1." 
::={ ianaIppmMetrics 21} 


ietfOneWayLossPeriodStream OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-Way-Loss-Period-Stream" 
REFERENCE " RFC3357, section 5.4.2." 
::={ ianalppmMetrics 22} 


ietfOneWayLossNoticeableRate OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-Way-Loss-Noticeable-Rate" 
REFERENCE " RFC3357, section 6.1." 
::= { ianaIppmMetrics 23 } 
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ietfOneWayLossPeriodTotal OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-Way-Loss-Period-Total" 
REFERENCE " RFC3357, section 6.2." 
::= ( ianaIppmMetrics 24 ) 


ietfOneWayLossPeriodLengths OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-Way-Loss-Period-Lengths" 
REFERENCE " RFC3357, section 6.3." 
::= { ianaIppmMetrics 25 } 


ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-Way-Inter-Loss-Period-Lengths" 
REFERENCE " RFC3357, section 6.4." 
::= { ianaIppmMetrics 26 } 


-- RFC 3393: "IP Packet Delay Variation Metric 
== for IP Performance Metrics (IPPM)" 


ietfOneWayIpdv OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-ipdv" 
REFERENCE " RFC3393, section 2." 
::= ( ianalIppmMetrics 27 } 


ietfOneWayIpdvPoissonStream OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-ipdv-Poisson-stream" 
REFERENCE " RFC3393, section 3." 
::= { ianaIppmMetrics 28 } 


ietfOneWayIpdvPercentile OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-ipdv-percentile" 
REFERENCE " RFC3393, section 4.3." 
:= ( ianalppmMetrics 29 } 


ietfOneWayIpdvInversePercentile OBJECT-IDENTITY 
STATUS current 
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DESCRIPTION 
"Type-P-One-way-ipdv-inverse-percentile" 

REFERENCE " RFC3393, section 4.4." 

::= ( ianaIppmMetrics 30 } 


ietfOneWayIpdvJitter OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-ipdv-jitter" 
REFERENCE " RFC3393, section 4.5." 
::= { ianaIppmMetrics 31 } 


ietfOneWayPeakToPeakIpdv OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-peak-to-peak-ipav" 
REFERENCE " RFC3393, section 4.6." 
::= ( ianaIppmMetrics 32 } 


-- RFC 3432: "Network performance measurement with periodic streams" 


ietfOneWayDelayPeriodicStream OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"Type-P-One-way-Delay-Periodic-Stream" 
REFERENCE " RFC3432, section 4." 
:= { ianalppmMetrics 33 } 


END 
7. Security Considerations 
This module does not define any management objects. Instead, it 


assigns a set of OBJECT-IDENTITIES which may be used by other MIB 
modules to identify specific IP Performance Metrics. 


Meaningful security considerations can only be written in the MIB 
modules that define management objects. This document has therefore 
no impact on the security of the Internet. 
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